第15章 継続的インテグレーション：リリースに備える

15.1 ショータイム

リリースデプロイにおける失敗要員をなくすために継続的インテグレーションのプラクティスが存在する

Ex: ヒューマンエラー・タイプミス・バグ・チームメンバーの連絡ミスなど。。。

15.2 リリースの備える文化

リリースに備えるとは心構えをさしていて、「このソフトウェアが今日リリースされても構わない」と思える状態にすること

「ソフトウェアを開発しているよりも、ソフトウェアを使用している時間の方が長い」という事実に基づいてリリース備える

だがリリースの備えることは簡単じゃないし、期限厳守の開発をしているとプレッシャーになることもある。コードの質より期限を優先してしまって、ないがしろがしがち

上記の問題を解決するのが、継続的インテグレーションである

15.3 継続的インテグレーションとは

継続的インテグレーションとは、開発者がソフトウェアに加えた変更を取り込んで、ソフトウェアとして統合する作業を途切れることなく続けていく取り組み

開発者通しが同じファイルを作業をして、マージする時に競合処理を行うことがあるが、これは開発期間がながければながいほど競合処理が膨らんでいき、マージがむずがしくなる

リリースにおける自動ビルド時間は長くなると、自動ビルドを使用なくなるケースもあるため、最高でも10分程度、基本は5分内で終わらせること

15.4 どうすればうまくいくのか？

継続的インテグレーションの準備には以下が日打つよう

ソースコードリポジトリ

GitたSubversionなどにあたる

悲観的ロックモデル（1ファイル編集できるユーザーは1人まで）のツールは開発効率が落ちるので採用したらだめ

チェックイン手順

ビルドの自動化

作業単位を小さくしようとする姿勢

15.3 チェックイン手順を習慣づける

1. 開発者は最新のソースコードを取得する

2. 変更を加える：必要な作業を実行する

3. テストを実行する

4. 作業中に発生した更新差分を取得する：作業が完了したら最新のソースコードをもう一度取得する

5. 再度テストを実行する

6. チェックイン（プッシュ）

ビルドを健全にするためには、すべきこととすべきじゃないことがある

すべきこと

手元のソールが最新版であることを確認する

テストをすべて実行する

定期的にチェックインする

ビルドが壊れたらすぐになおす

すべきでないこと

ビルドを壊す

ビルドが壊れているのにチェックインする

失敗するテストをコメントアウトする

15.6 ビルドを自動化する

自動化されたビルドは継続的インテグレーションの屋台骨

コードのコンパイル・テストだけにとどまらず自動化できるものはすべて自動化する

自動化されたビルドは人間が実行するだけじゃなく、ビルドエージェントを通しても利用できる。チェックイン時に自動化されたビルドを実行することもできる